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SYSTEM AND METHOD FOR AUTOMATED FINANCIAL 
PROJECT MANAGEMENT 

BACKGROUND OF THE INVENTION 

Project management, especially in the area of corporate real 
estate project management, is traditionally a process which is driven by 
paper forms and documents. These paper documents include for example, 
purchase orders, work orders, contracts, Requests for Assistance (RFA), 
Requests for Proposals (RFPs), commitments, bids, invoices, messages 
(generic correspondence), meeting announcements and minutes, project 
close outs, complete punch lists, project evaluations, and departmental 
statistics. 

The processing of all of these various documents is very labor 
intensive, error prone and subjects the proposed projects to needless delays. 
For example, if the manager in charge of approving commitments is on a 
business trip for two weeks, a commitment requiring his or her signature 
might be delayed for that length of time. This might result in a situation that 
a vendor misses a window of opportunity in the two week period, thereby 
delaying the project for an additional six weeks, which in turn delays another 
vendor's initiation of work and so on. 

Furthermore, an increase in the number of requests for new 
construction or engineering projects increases the volume of documents that 
are processed by the project administration group and the accounting 
operations group. This in turn requires an increase in processing capacity 
through an increase in staff levels or overtime. Conversely, a decrease in 
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volume of requests lowers the productivity of the groups, as the staff levels 
are maintained to support the processing at the peak operations volume. 

SUMMARY OF THE INVENTION 

The present invention was originally designed to automate the 
project management process for the Corporate Real Estate and Facilities 
Department of the assignee of the present invention. Although originally 
designed for this type of real estate and facilities department, it is readily 
seen that the project management method and system of the present 
invention has wide applicability to most types of project management. 

The system is a collection of process and business objects that 
provide project management tools to support construction, renovations, 
maintenance and other projects. One primary function of the system is to 
automate the creation, processing an d approval cycles of the numero us 
documents involved with each project. The system and method of the 
present invention provides automation to support the following business 
processes. 

Strategic Space Planning. This function is responsible for 
determining how much space is required, demographic and market analysis 
of locations, and owned versus leased funding strategies. 

Client Management. The system allows project initiation and 
funding approval by clients throughout the corporation via a desktop 
browser coupled to the system via a corporate intranet. This concept 
facilitates self-service delivery. The request component allows clients to 
specify requirements for construction, renovation, relocation or office 
furniture. 

Project Support. The system assists the real estate department 
staff in creating budgets and controlling how budgets are dispensed though 
purchase orders, work orders and contracts. This includes the table 
maintenance involved in vendor authorization, workload, reassignment of 
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tasks, security access and security registration, and changes to processes. 
Project support is provided for the administrative processes such as 
administering roles and responsibilities, which includes signing authority. 

Project Management. The business objects of the system of 
the present invention assist a project manager in creating a project budget 
and controlling how that budget is dispensed through purchase orders, work 
o rders and contract s. Invoices are processed against the commitments and 
are paid through an electronic accounts payable interface. The underlying 
system structure provides standardized work processes through processing 
templates. The system provides automated control and management of the 
process. This methodology is expandable because it is template based, 
thereby providing an environment for financial based project management. 
Additionally, Project Management includes phases of project initiation, 
predesign, schematic design, design development, construction documents, 
procurement, preconstruction, construction, and post construction. The 
system includes project management functionality to assist in: Tracking 
Project Milestones; Corporate Cost Center Allocations for identifying how 
project expenses should be charged; Messages which are generic 
correspondence; Meeting Announcements and Minutes; Creation and 
approval of commitments; Approval of invoices; Project Close Outs; 
Complete Punch Lists; Project Evaluations; and Departmental Statistics. 

Vendor Management. The system allows direct access via the 
Internet to provide extensive functionality for managing approved vendors in 
relationship to specific projects. This functionality allows an approved 
vendor to author Bids, Requests for Quotes (RFQs), Invoices, Punch Lists, 
Lien Waivers and Messages. Other documents can be received and 
processed with more limited functionality. These documents include 
Request for Proposals, Contracts, Work/Purchase Orders, Change Orders, 
Payment Confirmations and Meeting notices. In addition, an in-box allows 
for timely communications of messages and documents. 
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The present invention automates the creation, processing and 
approval cycles of numerous documents involved in project management. It 
allows project initiation and funding approval by clients throughout the 
corporation via a desktop browser coupled to a corporate Intranet, A 
5 software application embodying the present invention and its underlying 
technology are appropriate for a paper intensive area. It reduces the 
approval cycle of projects. It automates the creation, processing and 
approval, cycle of documents by routing documents electronically for on-line 
approval. 

1 0 Other objects, features, and advantages of the present 

invention will be apparent to one skilled in the art from the following 
description of the invention with reference to the accompanying drawing. 

BRIEF DESCRIPTION OF THE DRAWING 

For the purposes of illustrating the present invention, there is 
15 shown in the drawings a form which is presently preferred, it being 

understood however, that the invention is not limited to the precise form 
shown by the drawing in which: 

Figure 1 is an illustration of the structure of the system of the 
present invention; 

2 0 Figure 2 depicts the process flow of the present invention; 

Figure 3 illustrates the tree structure organization of project 
management data; 

Figure 4 depicts a user interface input screen for inputting a 
Request for Assistance; 
2 5 Figure 5 shows an approval hierarchy structure according to 

the present invention; 

Figure 6 illustrates a budget template and an example budget; 

Figure 7 depicts an On-call commitment to a vendor; 

Figure 8 shows a Purchase Order commitment; 
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Figure 9 illustrates the creation of a bid package; 
Figure 10 illustrates the bid opening processing; 
Figure 1 1 depicts the processing of bid responses from 

vendors; 

Figure 12 shows the processing of a vendor invoice; 

Figure 13 illustrates a funding document generated by the 
system of the present invention; 

Figure 14 depicts the close out information available to a 
project manager; 

Figure 15 illustrates a close out ledger; and 

Figure 16 depicts a partial closeout. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

Figure 1 illustrates the system 100 of the present invention . 
The various parties to the project managed by the system 100 communicate 
via a corporate Local Area Network (LAN) 105. Connected to the LAN 105 
are various servers 1 10-120 on which reside the applications and databases 
supporting the system 100. Server 115 contains the applications that enable 
the clients to initiate and approve project requests and approve funding for 
such projects. Work flow server 110 contains the applications which enable 
the project staff to create and route project documents and manage 
information. In a preferred embodiment, the workplace server 1 1 0 is 
accessed through an icon on the staffs' work stations 120 which operates in a 
windows environment. The applications can be developed using C, 
Powerbuilder™, SQL, Cold Fusion™, or other similar software 
development languages and tools. 

Database server 120 provides access to database 122 that 
contains the various databases housing the details of all of the projects under 
management. In a preferred embodiment, the databases on server 1 10 are 
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relational database such as is available from the Oracle™ corporation. 
Illustrated in Figure 1 is a work station 125, such as a personal computer 
(PC), laptop computer or other such workstations for use by project 
managers. Clients (employees of the corporation initiating projects) access 
5 system 100 through a corporate intranet 130 and client work stations 135. 
Vendors access system 100 using a vendor workstation 140 connect to the 
corporate LAN 105 preferably through the Internet 145 using a browser. 
The vendor workstation 140 uses a "thin" client technology meaning that the 
majority of the software for the vendor access resides on LAN 105 (servers 

10 1 10, 1 15). The firewall 150 provides all of the requisite security such as 
password protection, authentication and encryption (if necessary). 

System 100 provides security functions based on roles, signing 
authority and access rights. Security access is defined through a Role- 
Business Object-Function relationship. In addition, the ability to perform a 

15 function on an object (e.g., a document to be approved) depends on the state 
of the object. For example, as further described below, if a document has 
been approved, that document can no longer be modified so as to protect the 
integrity of the approval. Database 122 contains various tables that support 
the security function and allow definitions such as: Roles to Person table that 

2 0 identifies all the roles a person can perform; a Functions to Business Object 
table that identify all the functions and menu items available to a Business 
Object; a Tree- views to Role table that identifies all the treeviews (described 
below) available for a role; a Functions to Role table used to classify the 
functions and menu items as enabled or disabled for each business object 

2 5 within a role; a Function Exceptions table that overrides the classification for 

functions and menu items for each business object within a role identified at 
the person level (in other words, include or exclude a specific function in 
this business object for a person playing this role). A further table contains 
the state of all of the objects being managed by the system. A history of the 

3 0 revisions to an object (e.g., the changes in state during the approval process 
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of a document) is maintained for auditing purposes. An object in the present 
invention can have multiple documents associated therewith. For example, 
if the object is a bid, some of the documents associated with the bid could be 
a list of vendors (requiring approval) and a commitment (requiring its own 
5 separate approval). 

Figure 2 illustrates a overview of the project process managed by the 
present invention. The process begins with a client 160 determining that 
there is a need for the creation of a project. In the preferred embodiment the 
project is a construction project. The client 160 initiate the project by 

1 0 generating a Request for Assistance (RFA). The Request For Assistance is 
typically generated by the client 160 with the assistance of a project manager 
170. The process of generating an RFA with the aid of a project manager 
170 is an iterative one that involves preparation, negotiation, performance 
and acceptance. The RFA contains the nature and scope of the project, the 

15 funding available for and required by the project, and the schedule by which 
the project must be complete. Although the RFA can be communicated by 
telephone call or e-mail, in a preferred embodiment of the present invention, 
the RFA is generated by the client 160 using system 100. Specifically, the 
client uses its workstation 135 to connect to LAN 105 through the corporate 

2 0 intranet 130 (Figure 1). The applications on web server 1 1 5 prompt the 

client 160 for all of the necessary information required to complete the RFA 
165. The data contained in the RFA 165 is stored in database 122 in 
separate files associated with the project. 

After the client 1 60 and the and project manager 1 70 have finalized 

2 5 the RFA, it goes through an approval process (described below) within the 

client management chain 162. Once the RFA has been approved by client 
management 162 is it automatically forwarded to facilities management 172 
for approval and assignment of a project manager 170. Once the project 
manager 170 has been assigned and receives the approved RFA, the project 

3 0 manager 170 uses the RFA as a blueprint. As shown in loop 173, the 
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project manager 170 can typically delegate portions of the project to other 
groups (e.g., design work and its management can be delegated to a design 
group within the organization). As will be further described below, the 
project manager 170 creates bid packages, purchase orders and or contracts 
5 175 which are used to solicit the work from vendors 180. Typically project 
managers 170 work with the various vendors 180 in refining the nature and 
scope of the project. The project managers 170 receive proposals from the 
vendors 1 80 who are bidding on the whole or pieces of the project under 
consideration. The communication between the project managers 170 and 

10 the vendors can occur using the telephone or e-mail, but preferably the 
vendors 1 80 communicate with the project managers using their 
workstations 140 through the Internet 145 and firewall 150. 

For larger projects, the result of the bidding and proposal process is a 
contract 175 which defines, in detail, the tasks to be preformed by the 

15 vendors 180 in completing the projects. The specific tasks to be 

accomplished can be defined via a Purchase Order, a facilities agreement or 
a service agreement. Typically, contract 175 is a master contract which 
defines the general nature of the project as well as the general nature of the 
relationship between the corporation and the vendors 180. Pursuant to the 

2 0 contract 175, the project manager 170 will generate specific commitments to 
vendors 1 80 to pay for specific tasks performed by the vendors 1 80. The 
contract 175 further provides for the ability of the project managers 170 to 
issue change orders to the vendors 180 as the scope of the project changes 
during the evolution of the project. 

2 5 Upon completion of a task, the vendors 1 80 issue an invoice 

1 85 to the corporation. The invoice 1 85 can be transmitted to the 
corporation via tradition paper method, but preferably is transmitted in an 
electronic form compatible with system 100. If received in paper form, an 
invoice 1 85 is scanned so that it is rendered in electronic form which can be 

3 0 incorporated into system 100 in database 122. The invoice 185 is reviewed 
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by a project analyst 190 for comparison with the contract and the 
commitment to the vendor 180. The invoice 185 then goes through an 
approval process by the project manager 195 according to the business rules 
for the project as further described below. Once approved, the payment on 
the invoice goes through an accounting process 200 in which the payment is 
validated and charged against the appropriate portions of the contract. The 
payment is then remitted 205 to the vendor either through a credit to the 
vendor's Demand Deposit Account (DDA), via check or via Electronic Data 
Interchange (EDI) remittance. 

Figure 2 has depicted the general process of how a project is initiated 
and managed. The remainder of the Figures will illustrate how system 100 
facilitates the initiation management and closure of the project process. As 
previously described, the workstations for managing the project process 
(120, 125 in Figure 1) operate in a windows environment although any other 
suitable network operating system (e.g., Unix) can be employed. System 
100 includes security procedures, such as sign-on procedures, as known by 
those skilled in the art. Figure 3 illustrates a typical user interface screen 
250 which will help explain the structure and functions of system 100. 

Information concerning projects managed by system 100 are 
preferably organized in folders 255 by projects. In a preferred embodiment, 
the folders 255 are organized in a tree structure 260. User interface 250 
illustrates one tree structure 260 of a particular project 270. System 100 
contains various predefined tree views of folders 255 which are selected 
using list box 265. Specifically illustrated in Figure 3 is a tree view entitled 
"My Projects" in list box 265. The tree view of "My Projects" illustrated in 
Figure 3 is the standard default view of system 100. The "My Projects" tree 
view is most frequently used by project managers and other support staff. 
Other tree views access information in a variety of ways. Other tree views 
include: a close out master view that lists all of the closed projects; a major 
expenditure plan view that lists all of the major projects; "my" major 
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expenditure plan view which lists the major projects which a particular 
project manager is managing; a personal view that is an information folder 
for use by the user to store data for activities not related to specific projects; 
a projects by business sector view that lists all of the projects, sorted by 
5 major business division; a project by facilities division view that lists all 
projects sorted by a specific facilities department within the corporation; a 
view of projects by location that lists all of the projects sorted by location; a 
view of projects by project manager that lists all of the projects sorted by the 
project manager managing the project; a projects being supervised view that 

10 lists all of the projects being managed by the staff of a manager within the 
corporation; a view of recently approved documents that lists all of the 
documents that a user has approved within a predetermined period of time 
(e.g., two weeks); a view of system tables that lists various categories of 
system data such as roles, user profiles, and signing authorities; and a vendor 

1 5 view that lists all of the vendors sorted by several categories. Although the 
above is not an exhausted list of all of the views capable of creation in the 
system 100 of the present invention, it is a preferred list of the views. 

Each of the user interface screens of the system 100 include toolbars 
275, 280 containing icons that provide short cuts to the functionality of 

2 b system 100. In a preferred embodiment, the icons on toolbar 275 are 

consistent across the user interface screens of system 100. These icons 
provide basic functionality to all screens such as a button for returning the 
user to default tree view, a print button which prints the screens, a close 
button which closes a screen in which the user is currently operating, a tile 
25 up button that returns the screen to the standard screen format with the tree 
view 260 on the left hand portion of the screen and the selected item on the 
right hand portion of the screen, and an exit button that is used to exit the 
system. 

The icons on toolbar 280 change from screen to screen, depending on 

3 0 the function being performed by the user. Some of the toolbar 280 icons 
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illustrated in Figure 3 include a new document icon 28 1 that produces a new 
document menu; a view notes button that produces a list of all notes created 
using the notebook feature of the present invention as further described 
below; a refresh button that renews and updates the tree view after 
5 completing an activity; a toggle tree button that toggles between the tree 

view and a full screen view of the selected item on the right hand portion of 
the screen; and a create note button that activates the notebook feature of the 
present invention. The icons on toolbars 275, 280 and other functions of the 
present invention are accessed using a standard input device of the user's 
1 0 workstation such as a mouse. The mouse is used to click on a button to 

activate a specific function, to select an item and to drag and drop items of 
information. 

As previously described, information is preferably presented to the 
user in a tree view 260. The specific tree view illustrated in Figure 3 

15 illustrates the folders 255 associated with the project 270. The user 

illustrated in Figure 3 only has a single project 270, otherwise the other 
projects associated with the user would be illustrated in the tree view area. 

Eleven folders 255 are shown as being associated with the project 
270. The project directory folder 282 contains a listing of all of the project 

2 0 team members as well as the project vendors. The list is populated from 
database 122 (Figure 1) as individuals or vendors are identified on the 
project. The Request For Assistance folder 284 contains the approved RFA 
form as described above. The budget and funding folder 286 contains all 
budget worksheets and funding documents. These documents include a 

2 5 preliminary funding document, a supplemental funding document and 

surrogate funding documents. Project task folder 288 contains the project 
tasks that are set up to assign portions of the approved budget to specific 
trades (e.g., plumbing) in preparation for creating commitments to vendors. 
Commitments by trade folder 290 lists all of the commitments that have 

3 o been prepared for a project (including draft, unapproved and approved 
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commitments). The approved commitments folder 292 contains all of the 
approved commitments. The payments folder 294 contains all approved 
invoices from vendors for which payment has been made. The bid 
documents folder 296 contains all information related to bids and bid 
5 waivers. Each bid listed in this folder is assigned a unique number for 

accounting tracking purposes. Reports folder 298 contains a tracking report 
with respect to the project which lists all commitments and payments. This 
folder can also be used to store copies of other reports. Projects attachment 
folder 300 contains sub-folders for storing scan documents or electronic files 

10 of plans, specifications, correspondence, schedules and furniture/finishes 

information for example. The close out folder 302 contains partial and final 
close out information with respect to the project. Again, the above list of 
folders 282-302 is not exhaustive and any folders can be created which suit 
the needs of the particular project being undertaken or the corporate system 

15 in which the system of the present invention operates. 

The right hand portion of screen 250 depicts the information 
associated with the folder selected on the left hand portion of the screen. In 
this particular example, the project 270 has been selected and accordingly, a 
profile 304 of the project is displayed on the right hand portion of screen 

2 0 250. The project profile 304 contains information related to the category of 
the project, the project number, the project name, the location of the project, 
the division for which the project is being conducted and the cost center 
associated with that division as well as the current phase of the project. The 
project profile further includes a brief project description 306 as well as an 

2 5 area 308 for the project status. 

Although not specifically illustrated in Figure 3, every document 
within system 100 has its own notebook in which is recorded comments, 
issues or status information associated with the project. The notebook 
feature can be activated at any time, such as while preparing a document, 

3 o during the approval process, or even after final approval. Notes can be 
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saved generally in three different categories. A first category is a comment 
which includes general notes for the facility staff. A second category of 
notes is the status of the project which contains on going project status 
information. This status information from the notebook is displayed in the 
5 status area 308 in the project profile area. The final general category of 
notes contains specific notes to be published to other members of the team 
such as the clients. The published notes are available to the clients as 
previously described through the corporate intranet 130. 

As previously described, the project management process initiated by 

10 a Request for Assistance (RFA). Figure 4 illustrates an initial user interface 
screen 350 for creating an RFA. The RFA is prepared either directly by a 
requestor or by a coordinator within the business unit requiring the project. 
There are generally two types of information required on an RFA, requestor 
information 352 and information related to the project requested 354. The 

1 5 input screen 350 allows the user to input all of the required information into 
an electronic RFA form. In a preferred embodiment, the electronic form is 
used for projects over a predetermined dollar amount (e.g., $10,000). If the 
project total is less than the predetermined amount, the user can e-mail the 
project and requestor information to the facility staff. The facility staff can 

2 0 then prepare an internal RFA on behalf of the requestor so that the request 
can be inputted and managed within the system 100 of the present invention. 

Once the RFA has been completed, the user saves the document and 
clicks on a button (not shown) to send the RFA for approval. This action 
brings up a client hierarchy screen 360 illustrated in Figure 5. This screen 

2 5 represents one of the unique features of the present invention. On screen 

360, the user is able to identify the proper personnel required to approve the 
RFA. In the specific example depicted in Figure 5, three separate approvals 
are required for the RFA. The first approval is a business unit manager 362, 
the second approval by a business unit controller 364 and the final approval 

30 by a business executive 366. Different rules are capable of being set in the 
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database 122 of system 100 such that depending on the scope of the project 
(typically the total dollar amount) the number of approvals will change. For 
example, for larger projects (e.g., above $100,000) a business unit executive 
366 will be required to approve the RFA. In area 368, the user is able to 
select the actual person who is fulfilling the role required for approval. The 
database of system 100 contains all of the relevant information with respect 
to each person in each business unit that can fulfill each role (e.g., name, e- 
mail address, title, etc.). The user can select the appropriate person from a 
drop down menu by selecting the down arrow on each box in area 368. 

Once the appropriate people have been selected for the approval roles 
with respect to the RFA, the user clicks on the submit button 370. This 
action automatically forwards the electronic RFA to the person fulfilling the 
role of the first level of approval required for the RFA. A notice of the 
pending RFA requiring approval is added to the workflow list of pending 
tasks of the approver. This workflow list is accessed by the approver using 
button 375. When activated, this button provides a list of all of the 
documents requiring the persons' approval. The approver is then able to 
click on the notice which will bring up the actual electronic RFA document 
for review by the approver. After the review is complete, the reviewer is 
able to type any notes into a comment area of the RFA document and select 
one of several actions. If the approver approves the RFA, the electronic 
RFA is sent to the next individual in the approval hierarchy. System 100 
enables electronic signatures as is well known to those skilled in the art. The 
approver can also return the RFA for clarifications to the previous approver 
or to the requestor. Such an action should be accompanied by the approver 
including notes in the comment area which further define the clarifications 
required. The approver can also disapprove the RFA which sends the form 
directly back to the requestor or client coordinator. Again, if the RFA is 
disapproved, the approver should include notes in the comment area 
including reasons for the disapproval. Finally, the approver can discontinue 
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the review of the RFA and come back to complete the review at a later time. 
In this action, the notice of the pending RFA will remain in the approver's 
work list. If the RFA is approved by the final approver in the client 
hierarchy, the form is automatically routed to a dispatcher in the project 
5 management staff. At this point, the approved RFA is assigned a project 
number and a project manager. 

The automatic approval process of the present invention has several 
distinct advantages. First, the process is instantaneous. Once a document 
has been submitted for approval, notice of the receipt of the document for 

10 approval is immediately sent to the approver and the document is 

immediately available for review. This is in sharp contrast to the prior art 
method of approval in which documents typically were rerouted using 
interoffice mail. Apart from the delay associated with such a mail system, 
documents were often lost or misplaced. Tracking the status of approvals 

15 using the present invention is as simple as clicking on a button on the user's 
screen. The prior art required someone to conduct a series of phone calls, e- 
mails and personal visits to the approvers. Another advantage of the 
approval hierarchy of the present invention is that it recognized the corporate 
reality that people often change jobs, responsibilities, and locations. If such 

20 a change occurs, the database 122 of system 100 is easily modified to reflect 
the change. For example, if someone having the role of an approver is 
promoted and another person takes over the role, the database can be easily 
modified to replace the promoted person with the successor. Any 
subsequent approvals will then be automatically forwarded to the successor. 

2 5 Similarly, if someone having a role is on a temporary leave or absence, any 

task assigned to that person (e.g., approvals) can be easily and temporarily 
reassigned to a substitute person. 

Additional functionality provided to the clients of system 100 is the 
ability to view a list of RFAs for its business unit by clicking button 378. 

3 0 This button will bring up a window containing all of the RFAs of the 
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business unit. The list will include the project name, the date prepared, the 
status of the RFA and the status of the funding of the project. In a similar 
manner, a client is able to view a list of all of the funding documents by 
clicking on button 380. The funding list will display all of the funding 
5 documents for projects on which the user is involved. Once a list is 

displayed in the system 100 of the present invention, the user is able to view 
the actual documents associated with the item by selecting the particular 
item. 

After the approved RFA has been received by the project staff, one of 

1 o the first tasks for the project staff is to create a budget and funding 

documents for the project. Figure 6 illustrates a user input screen 400 for 
creating budgets and funding documents. In a preferred embodiment, 
budgets are created using predefined templates. Area 402 allows the user to 
view a list of all of the budget templates available within system 100. These 
15 templates can either be global (general formats available to all personnel) or 
private (i.e., templates that the user has personally created for his or her own 
use). Once a template is selected, the template is displayed in area 403 on 
the left hand portion of screen 400. In the preferred construction 
embodiment of the present invention, the templates contain, three levels of 

2 0 project information, including individual trades (e.g., lighting fixtures), trade 

categories (e.g., electrical) and summary categories (e.g., construction, 404 
in Figure 6). The templates in area 403 can be viewed in the standard view 
as illustrated in Figure 6, or a tree view as previously described, that shows 
summary categories in expandable folders. 

2 5 Once the template is displayed, the user is able to create the unique 

budget for the project in area 406 by dragging and dropping the items from 
the template area 403 into the budget area 406. For each item in the budget, 
the user is required to input the unit 408, quantity 410 and price 412. Once 
these items 408-412 have been input by the user, system 100 automatically 

3 0 calculates the cost of the item 414. Additionally, system 100 allocates the 
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cost as a capital item 416 or an expense item 418. System 100 additionally 
calculates an allowed contingency amount 420 which can be set in the 
system as a percentage of the cost (e.g., 10% of the capital cost). The user is 
able to increase or decrease this contingency amount in area 422. 
5 If the creation of the budget document lasts longer than the user 

session, the user can save the budget as a worksheet and come back at a later 
time and complete the budget. Once the budget has been finalized, it is 
saved in a final form. The budget is then used to create a funding document 
that requires approval. The budget is a very complex and detailed 

10 document(s) that potentially includes hundreds of trades, capital items, 

expense items, etc. Rather than have the client and facilities management 
approve the very detailed budget, the system of the present invention 
generates a funding document for approval. An example of a funding 
document is depicted in Figure 13. The funding document of Figure 13 was 

15 generated by a template accessing data from the database containing the 

budget. It is appreciated that any template .can be used to generate any type 
or form of funding document desired. As seen in this Figure, the funding 
document summarizes the capital items for the project 700 as well as the 
expense items 705. These summaries 700, 705 provide the approvers with 

2 0 an overview of the total spending for the project without the complexity of 
the details of the entire budget. Further shown in Figure 13 are the names 
of the approvers of the funding document as well as the dates of the 
approval. The funding document indicates approval by both the facilities 
department 710 as well as the management of the business unit 715. 

2 5 As previously described with the approval process for an RFA, the 

project staff member submits the funding document for approval which is 
automatically forwarded to the facilities hierarchy for approval. Again, the 
first person in the facilities hierarchy receives a notice in his or her work list 
regarding the funding document to be approved. The same automatic 

3 0 forwarding of approved documents is follows as described above with 
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respect to an RFA. Again, if at any level of the approval process the 
reviewer denies approval or requests further clarification, the funding 
document is automatically returned to the previous approver with notes in 
the comments section providing reasons for the disapproval or the required 
5 clarification. Once the funding document has been approved by all levels of 
the facilities hierarchy, it is automatically forwarded to the client hierarchy 
for its approval. In a preferred embodiment, the client business unit has a 
similar level hierarchy for approvals, depending on the scope and size of the 
project. The same approval process is repeated within the client business 

10 unit including automatic forwarding of approved funding documents. Once 
the funding document has received final approval from the client hierarchy, 
it is automatically forwarded to the assigned project manager who 
acknowledges the approved funding document. The funds are now available 
for commitments and the process of managing the project begins. 

15 With the approved RFA and budget in place, the project manager is 

able to begin the actual project management. This process starts with the 
project manager generating commitments to vendors for various aspects of 
the projects. In the preferred construction embodiment of the present 
invention, the commitments include: architectural/engineering on calls; 

2 o Purchase Orders; bids; bid waivers; contracts; change orders; and work 

orders. Architectural/engineering on-calls are commitments for on-call 
consultant services which typically result in the generation of a purchase 
order. A Purchase Order is a commitment for goods, materials, equipment 
or services, typically up to a predetermined dollar amount (e.g., $25,000). In 
25 the preferred embodiment, commitments over the predetermined amount 
(e.g., $25,000), require competitive bids. Again, these bids result in 
purchase orders for goods, materials and equipment or contracts for the 
provision of services. Alternatively, for commitments over the 
predetermined dollar amount, biding can be waived pursuant to a special bid 

3 0 waiver approval process. Work orders are commitments made against a 
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master contract with a vendor for certain services of any dollar amount and 
for other trade services up to a predetermined amount (e.g., $10,000). 
Change orders are amendments to previously approved purchase orders or 
contracts, either increasing or decreasing the dollar amount. The change 
5 order results in a revised purchase order or a revised contract. 

The commitments are created against the previously approved 
funding and begin with the creation of a project task that assigns a portion of 
the approved budget to a specific trade. In order to create a project task for a 
commitment, the project manager selects the new document icon (281 in 

10 Figure 3) to create the task. Activation of this icon 281 displays a document 
selection menu which includes the various documents which the project 
manager is able to create. A selection exists for each of the above-identified 
types of commitments (e.g., an on-call commitment). By selecting one of 
the items, the project manager is required to complete a description of the 

15 project task including the trade, the protocol for the commitment (e.g., 
source, bid, waived bid, negotiated, national contract), the type of 
commitment (e.g., purchase order, contract, work order) the tax status of the 
commitment (e.g., taxable, nontaxable) and a detailed description of the 
scope of work to perform pursuant to the commitment. 

2 0 The project manager is further required to complete a trade code 

details section. All of the trade codes that are contained within the approved 
budget are displayed (e.g., electrical). The project manager is able to drag 
and drop the applicable trades from the project budget to the trade code 
portion of the project task. The project manager then types in the dollar 

2 5 amount for each applicable trade for the commitment. Once the project 

manager has completed the above, the project manager saves the project 
task and is then able to generate the actual commitment. 

Figure 7 illustrates a complete commitment request 450 for an 
architectural/engineering on-call. In creating this commitment 450, the 

3 0 project manager was prompted to enter information related to the project 
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455, information related to the consultant (vendor) 460, the scope of the job 
and the square footage affected and the fees associated therewith 465, as 
well as a summary of the funding and financial commitments 470, both with 
respect to this particular commitments and the project in total. Many of the 
5 items found on this on-call commitment were obtained from pull down 
menus (not shown) such as the consultant. Other items such as the cost 
center to be changed for work performed are provided by system 100 as a 
default once the project number is inputted by the project manager. Once 
the on-call commitment has been completed by the project manager, the 

1 0 project manager submits the commitment for approval to the project staff. 

As previously described, the approval process is automatic, with each level 
of approval being able to approve the document, disapprove the document or 
return the document for clarification. 

In addition to the electronic commitment, system 100 provides the 

15 project manager with the capability of scanning in additional documents that 
are associated with the commitment or creating any attachment such as 
spreadsheets, JPEG files, drawings. In the preferred embodiment, such 
attachments are created using Object Linking and Embedding (OLE) 
compliant software. Additional documents attached to a commitment may 

2 o include proposals from the consultant or vendor. These attachments are 
available for review by the approvers at their work stations by selecting a 
view menu and selecting the attachments choice on the view menu (not 
shown). 

Once an on-call commitment request has received final approval, 

2 5 system 100 automatically generates a purchase order number and notifies the 

project manager (electronically) of the purchase order number. A hard copy 
of the purchase order is issued by the project staff to the vendor. Preferably, 
the vendor is also able to obtain an electronic copy of the purchase order 
through the Internet interface previously described with respect to Figure 1 . 

3 0 The purchase order contains all of the basic information contained in the on- 
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call commitment request as illustrated in Figure 7, In the preferred 
embodiment, when the vendor opens the electronic purchase order (or other 
document such as a contract or a change order), the vendor is presented with 
a set of appropriate functions. For example, for contracts, a command 
5 button will be provided to Agree to the terms or Not Agree with an 

opportunity to comment or create addendum. The Agree function invokes 
an electronic signature process. Some functionality may not be available 
based on the stage of a particular process. For example, invoices cannot be 
created until a work document has been accepted. 

10 In the preferred embodiment, records relating to a vendor remain 

available in system 100 for a period of at least one year following the job's 
completion. Documents the vendor can author include Bids, RFQs, 
Invoices, Punch Lists, Lien Waivers and Messages. Documents the vendor 
can receive and process with limited functionality are Request for Proposals, 

15 Contracts, Work/Purchase Orders, Change Orders, Payment Confirmations 
and Meeting notices. In this preferred embodiment, the vendor is only 
allowed to view documents they authored or documents intended for them. 
The ability to delete documents are limited from a vendor's perspective and 
may only be allowed depending on the state of a document. This will 

2 0 provide for a document draft feature prior to posting to the workflow. 

The generation of a project task for purchase orders is the same as 
described above with respect to on-call commitments. Figure 8 illustrates a 
request for a purchase order commitment 475 generated by system 100 of 
the present invention. The project profile information 455 is the same as 

2 5 described above with respect to the on-call commitment. The commitment 

information 480 includes the trade involved, the type of commitment (a 
purchase order in this example) and the protocol for the commitment. The 
vendor information 485 describes the vendor to which the Purchase Order is 
to be issued. Again, this information can be input by the project manager 

3 0 using drag and drop methods previously described from a master list of 
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vendors for the selected trade. The selection of vendors can either by from 
all of the vendors contained in the system or from vendors with which the 
corporation has a master contract. The cost associated with the purchase 
order is entered in area 490 and the summary of the financial commitments 
5 is again listed in area 470. As with the on-call commitment described above, 
the project manager is able to scan non-electronic documents into the system 
for attachment to the purchase order. Once the purchase order request has 
been saved, it can be submitted for approval and proceeds through the 
approval hierarchy as previously described. Upon final approval, the 

10 purchase order is issued to the vendor with notification being made to the 
project manager electronically. 

A project task for a bid is again created as described above. Once the 
project task has been created, the project manager is then able to create a bid 
package 500 as illustrated in Figure 9. System 100 automatically assigns a 

15 bid number 502 to the bid package as well as assigning the bid status 504 of 
"initialization". As previously described, a bid is an object that can have 
many documents associated therewith. Each document can have a separate 
approval process as described above. There is not necessarily a one to one 
relationship between documents and the object with which they are 

2 0 associated. The trade 506 is obtained by the system from the information 
provided by the project manager in the creation of the project task. The 
project manager then inputs the invitation and bid due dates 508 and 510 as 
required by the project. The contract type 512 is selected by the project 
manager from a pull down menu (not shown). The project manager further 

2 5 inputs any special instruction in area 514. The bid package total 5 1 8 is 

automatically calculated by the system as the sum of the tasks 520. The 
tasks 520 are initially populated by system 100 from the entries input the 
project manager when creating the project task. The project manager can 
add additional tasks in area 520 that he or she desires to be bid upon. The 

3 0 task can relate to the same project number or be associated with different 
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projects. The price options 522 defaults to a base price, but the project 
manager can select alternative pricing options from a pull down menu (not 
shown). The documents supporting the bid are listed in area 524 and include 
such documents as architectural or engineering drawings as well as 
equipment specifications. 

Once the bid package has been saved. The project manger is 
provided with a bid package vendor selection screen that allows the project 
manger to choose the vendors from which bids will be requested. Again, the 
project manager is able to select the vendors from a list complied from the 
database 122 in system 100. Once the project manager has finished 
selecting the vendors from which bids will be requested, the list is saved and 
submitted for automatic approval as described above. Once the list of 
proposed bidders has been approved, the bid package is sent to each of the 
bidders in hard copy form and preferably in electronic form. 

Prior to the bid due date, the bidders submit their bid proposals in 
response to the bid package. Due to legal concerns, it its preferable that the 
bids be opened arid witnessed by two and preferably three witnesses. Figure 
10 illustrates an input screen 550 used for conducting the bid opening. As 
illustrated in this Figure, three witnesses 552 are provided. System 100 
requires these witnesses 552 to input their IDs and passwords when 
conducting the bid opening. As each bid is open, the information from each 
vendor is input into area 554. The vendor name and the price options are 
defaulted by the system 100 from the approved proposed bidder list 
previously described. The amount 556 is obtained from the vendors bid and 
is input into the system by the project staff. Additionally, the actual bid 
documents are scanned into system 100 and linked as attachment to the 
project. Once all of the bids from the selected bidders have been entered, the 
bid responses on screen 550 is saved and the bid opening is officially closed. 
The project manager is now able to perform an evaluation of the bids. 
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In performing the bid evaluation, the project manager selects the bid 
documents folder (296 in Figure 3) to view the various bids. The bid 
documents folder contains all of the bids associated with the selected project. 
Selecting a modify button (not shown) activates a bid evaluation screen 560 
5 as illustrated in Figure 1 1 . As seen in screen 560, each of the bidding 

vendors is displayed. The project manager is able to enter a qualified price 
562 which is either the bid amount submitted by the vendor during the 
bidding process or an adjusted amount due to clarifications with the vendor 
after the bid has been opened. The project manager is additionally able to 

1 o enter any comments on the pricing in area 564 with respect to each of the 

vendors. The project manger is then required to rank the vendors in area 566 
and provide a reason for selecting a particular vendor in area 568. If 
addition documents have been submitted by the vendors, they can be 
scanned in and attached to the data for project as well as other attachment 
15 such as drawings. Once the project manager has completed his or her 

ranking 556, the bid evaluation is saved and submitted for approval. The 
automatic approval process proceeds as described above with respect to the 
approval hierarchy. 

The above has described a process for creating and approving three 

2 0 types of commitments, namely architecture/engineering on calls, purchase 

orders and bids. Similar processes are performed for the creation and 
approval of bid waivers, work orders and change orders. These processes 
shall not be specifically described herein, those skilled in the art appreciated 
how such processes are accomplished. 

2 5 After the commitments have been made to the various vendors and 

the work has been completed, the vendors submitted invoices for the 
services and materials provided pursuant to the commitments. In a preferred 
embodiment of the present invention, the invoices are electronically 
transmitted from a vendor workstation 140 (Figure 1) through the Internet 

3 0 145 and the firewall 1 50 for receipt by system 100. Alternatively, paper 
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invoices may be submitted, scanned and the data entered into the system 
either manually or through drag and drop methods. The project manager 
reviews the invoice data contained in system 100 against the scanned copy 
and makes any necessary adjustments in the payment amount, retainage, 
5 freight/delivery or tax, based on the actual goods or services provided. 

Figure 12 illustrates an example of an invoice data entry screen 600. 
After an invoice has been received, the purchase order number 602, the 
invoice number 604 and the invoice date 606 are entered. System 100, using 
the purchase order number 602, automatically fills in the commitment 

10 information 608 as well as the vendor information 610. The amount of the 
invoice including the material amount, the freight amount and the taxable 
amount are entered in area 612. Once the data has been entered on invoice 
data entry screen 600, the data is saved and submitted for approval. The 
invoice approval process follows the approval hierarchy described above 

1 5 with respect to the other documents generated by the system. In a preferred 
embodiment, if the invoice amount does not exceed the commitment 
amount, the project manager alone can approve the invoice. If the invoice 
amount does exceed the commitment amount, the project manager can 
prepare a change order. The change order requires approval through the 

2 0 hierarchy and the issuance of a revised purchase order reflecting the adjusted 

commitment amount. Once the invoice has been approved, the payment can 
be made to the vendor either through the issuance as by check, crediting of 
the vendors demand deposit account, or through other EDI means. 

One further advantage of the present invention is the automatic nature 
25 of the tracking of the accounting information. A general rule is that any 

required accounting information (e.g., the business unit to which items will 
be charged) is captured by the system as soon as possible and thereafter 
carried through throughout the project. For example, once the client 
identifies the business unit to be charged, this identification is automatically 

3 0 carried into the templates for the project, commitments and invoices. All 
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documents created from these templates will therefore automatically carry 
the identification of the business unit to be charged. 

As briefly described above, one of the features of the present 
invention is the ability to automate the close out process. The process of 
5 closing out a project has historically been an arduous and manually intensive 
process. As previously described, the preferred embodiment of the present 
invention relates to construction projects, and the close out process will be 
described in terms of this embodiment. The closeout procedures of the 
present invention automate the financial transactions associated with the 

10 following two processes: handling of a project's CIP (construction-in- 
progress) account balance; and the final closing of a project. 

The CIP account is a holding account that captures a construction 
project's capital expenditures. At the end of the project, the balance in the 
CIP account is passed to a fixed asset (F/A) account for depreciation. Until 

1 5 the asset has been4hus transferred, it cannot be depreciated. After the 
balance is passed to a fixed account it starts depreciating thus creating 
depreciation expenses for portion of the corporation that is benefitting from 
the project. There is no hard requirement for the construction project to be 
100% complete in order to commence depreciation. Depreciation can start 

2 0 with the payment of the first invoice with respect to the project. Typically, 
financial accounting rules governing construction projects employ an 80% 
threshold for commencing depreciation (i.e., 80% of the project must be 
complete before depreciation is started). The specifics of a project might 
require for the depreciation to be started both before or after an 80% 

2 5 threshold is reached. 

As previously described, many of the processes of the method and 
system of the present invention are driven by the documents related to the 
project. The final closing of a project in the system of the present invention 
is a system controlled procedure that starts with automatic examination of 

3 0 various states of the project documents. As a result of this thorough 
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examination, the system produces an on-line diagnostics which highlights all 
inconsistencies detected by the process. The problems are categorized and 
displayed for the project manager. 

The system performs several types functions related to close outs, 
5 including a partial close out, a full close out, abort a close out and cancel a 

close out. A partial closeout is a type of closeout that is done when there is a 
need to move a portion of CIP balance to a F/A account. On larger projects, 
either in terms of funds and or the period of time for completing the entire 
project, having multiple partial closeouts is a very useful function practical. 

10 A full closeout is a type of closeout that is performed by the project manager 
only once. After successful completion of full closeout the project is closed 
to any further activity (including commitments and payments). A Cancel 
closeout is a type of closeout that is performed by the project manager in a 
case where a project was initiated in the system of the present invention but, 

15 before any commitments were issued to the vendors or any invoices were 
paid, the decision was made to stop it. An abort closeout is a type of 
closeout that is performed by a project manager when the client requested to 
stop the project after the funding was approved, commitments were issued 
and/or invoices were paid. 

2 0 A trigger built in the system initiates the first partial closeout for a 

project when the payment of a particular invoice meets the 80% threshold. 
The 80% threshold is with respect to the entire project. This trigger for a 
partial close out can be set to occur with respect to any event that is kept 
track of in the system. For example if there are several phases of a project, 

2 5 the trigger can cause a partial closeout at the completion of a particular 

phase. The trigger initiates a workflow process gets started that opens a 
closeout session. The system automatically links all of the paid invoices for 
the project to the closeout session created by the trigger. The system also 
generates a substantial number (sometimes hundreds) of financial 

3 0 transactions that will be sent to the General Ledger (G/L). 
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The work flow process sends the generated transactions to an analyst 
in the financial area. After reviewing the transactions, the analyst approves 
the session. This single automated procedure alone replaces a substantial 
manual effort (document collection, data entry, data validation, etc.,) which 
5 would take weeks or even months to complete. The financial analyst can 
request that the system start a partial closeout if needed. In the preferred 
embodiment, there is no system-imposed limit on the number of partial 
closeouts that can be processed by the system. 

Fig. 14 illustrates the close out information that the system makes 

1 0 available to the project manager. As previously described with respect to 
Fig. 3, the tree structure of folders in the project manager's directory 
includes a close out folder 800. Opening the close out folder brings up the 
screen 802 seen in the left hand portion of Fig. 14. Close out screen 802 
contains six tabs 805-830 for viewing further information with respect to the 

15 status of the various close outs with respect to a project. 

As illustrated in screen 802 in Fig. 14, the Financial Summary tab 805 
displays a summary of the overall financial status of the project. 
Information in area 835 provides identification of the project, while the 
information in area 840 summarized the actual financials. The financial 

2 0 information in area 840 includes the budget for the project, the amount of the 
budget that has been committed, the amount of the commitments that have 
been paid, the percentage of the budget that has been paid, the retainage held 
and the retainage paid. On this single summary screen 802, the project 
manager is quickly able to obtain a summary of the progress, from the 

2 5 financial point of view, of the project. 

Each of the other tabs, commitments 810, unapproved budget 815, 
unapproved commitments 820, change orders 825 and invoices 830 
respectively bring up screen that detail the status of the subject matter related 
to the items associated with the tab. For example, the commitments tab 820 

3 0 brings up a screen (not shown) that shows in detail all of the commitments 
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that were created in the system. For each commitment, the screen shows the 
vendor to which the commitment has made, the category (e.g., construction, 
move) the amount of the commitment, the amount paid to date and the 
remaining balance of the commitment. The remainder of the tabs 810-830 
5 bring up similar screens that list all of the items associated with the tab. 

The folders Closeout Ledger 850 and Partial 860 in the project 
manager's tree directory contain further information related to the closeout 
status. The closeout ledger folder 850 bring up a screen 900 as illustrated in 
Fig. 15. This ledger screen 900 includes a summary are 905 and a detailed 

1 0 area 910. Within the detailed area 9 1 0, there is an entry for each of the 

closeouts associated with the project. In the particular example depicted in 
this Figure, only a single partial closeout has been executed with respect to 
the project. Fig. 16 illustrates the details associated with a partial closeout. 
Area 950 lists the project information and the project details are listed in 

15 area 955. Area 960 contains the details as to the G/L accounts to which the 
items in the partial closeout were assigned. Area 970 details the different 
G/L accounts to which items were posted as well as the depreciation 
schedule that is assigned to the items. 

When a project has been completed, the project manager initiates a 

2 0 final closeout. Again, the full level of automation associated with the partial 
closeout as described above is applied to the full close out. In contrast to a 
partial closeout though, additional tests are performed to make sure that no 
unfinished business associated with the project is left unattended. For 
example, one test is performed to expose any unpaid invoices. Another test 

25 is performed to identify any commitment that is not fully paid. A further test 
is performed to identify any credit from a third party (e.g. a real estate) due 
to the project that is not collected. And so on. A full diagnostic of the state 
of the project is presented to the project manager in a manner of seconds and 
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a list of actions required is fully identified. In the prior art manual process, 
this undertaking would have required days if not weeks to complete. 

To close projects that were canceled before they were started and 
those that were stopped after they were started, two other types of closeout 
processing are performed as previously described, Cancel closeouts and 
Abort closeouts. Various tests are performed by the system to help the 
project manager to handle these exceptional conditions correctly. 

Although the present invention has been described in relation to 
particular embodiments thereof, many other variations and other uses will be 
apparent to those skilled in the art. It is preferred, therefore, that the present 
invention be limited not by the specific disclosure herein, but only by the 
appended claims. 
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WHAT IS CLAIMED IS : 

1 . A method for automating the management of a project, the method 
comprising the steps of: 

generating at least one electronic document associated with the 
project; 

identifying entities that comprise an approval hierarchy; and 
automatically forwarding a notice requesting approval of the at least 
one electronic document to a successive one of the entities in the approval 
hierarchy upon approval of the at least one electronic document by a 
previous entity in the approval hierarchy. 

2. The method as recited in claim 1, the method further comprising 
the steps of: 

one of the entities in the approval process requesting clarification 
with respect to the at least one electronic document; and 

automatically forwarding the at least one electronic document to one 
of a previous entity in the approval hierarchy and the document originator 
for the requested clarification. 

3. The method as recited in claim 2, the method further comprising 
the steps of: 

opening an electronic notebook associated with the at least one 

electronic document; 

generating the requested clarification in the electronic notebook; and 
forwarding the at least one electronic document back to the entity that 

requested the clarification. 

4. The method as recited in claim 1, the method further comprising 
the steps of: 
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one of the entities in the approval process disapproving the at least 
one electronic document; and 

automatically forwarding the at least one electronic document to one 
of a previous entity in the approval hierarchy and the document originator. 

5. The method as recited in claim 1, the method further comprising 
the step of: 

determining if a monetary value associated with the at least one 
electronic document requires that at least one electronic document obtain the 
5 approval of a higher level entity in the approval hierarchy. 

6^ The method as recited in claim 1, the method further comprising 
the step of temporarily substituting a substitute entity for one of the entities 
in the approval hierarchy. 

7. The method as recited in claim 1, further comprising the step of 
maintaining the at least one electronic document in a central storage location 
to which the entities in the approval hierarchy can access, review and 
approve the at least one electronic document. 

8. The method as recited in claim 1, wherein the at least one 
electronic document is a request for assistance that initiates the project. 

9. The method as recited in claim 1, wherein the at least one 
electronic document is a contract. 

10. The method as recited in claim 1, wherein the at least one 
electronic document is a commitment with respect to a vendor on the 
project. 
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1 1 . The method as recited in claim 1 , wherein the at least one 
electronic document is a bid. 



12. The method as recited in claim 1, wherein the at least one 
electronic document is a funding document that contains the funding for the 
project. 

13. The method as recited in claim 1, wherein the at least one 
electronic document is a purchase order. 

14. The method as recited in claim 1, wherein the at least one 
electronic document is a change order. 

1 5. The method as recited in claim 1, wherein the at least one 
electronic document is an invoice approval document. 

16. The method as recited in claim 1, further comprising the step of 
attaching a digital signature to the at least one electronic document in order 
to indicate the approval of an entity in the approval hierarchy. 

17. The method as recited in claim 1, wherein the electronic 
document is generated by a client and wherein the approval hierarchy is a 
client approval hierarchy, the method further comprising the steps of: 

identifying project management entities that comprise a project 
management approval hierarchy; and 

automatically forwarding a notice requesting approval of the at least 
one electronic document to a successive one of the project management 
entities in the project management approval hierarchy upon approval of the 
at least one electronic document by a previous project management entity in 
the project management approval hierarchy. 
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18. The method as recited in claim 1, wherein there are a plurality of 
electronic documents, the method further comprising the steps of: 

organizing the plurality of electronic documents into folders; and 
providing a plurality of views of the plurality of electronic 
documents. 

19. The method as recited in claim 1, further comprising the steps of: 
. establishing a user profile for each user participating in the method; 

and 

limiting a user's access to the at least one electronic document based 
on a parameter in the user profile. 

20. The method as recited in claim 1 , further comprising the step of 
generating an electronic workflow list for a user that contains a list of 
electronic documents that require an action by the user. 

21. The method as recited in claim 1, wherein the step of 
automatically forwarding the notice further comprises forwarding the notice 
on an intranet. 

22. The method as recited in claim 1, further comprising the steps of: 
generating a budget for the project; and 

generating a funding document using the budget, wherein the at least 
one electronic document is the funding document. 

23. The method as recited in claim 22, wherein the step of generating 
the budget further comprises the steps of: 

selecting one of a plurality of pre-existing templates for the budget, 
the selected template containing a plurality of selectable budget items; and 
selecting at least one of the selectable budget items. 
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24. The method as recited in claim 23, wherein the step of selecting 
the at least one of the selectable budget items farther comprises the step of 
using a drag and drop method. 

25. The method as recited in claim 1, farther comprising the step of 
attaching at least one other electronic file to the at least one electronic 
document. 

26. The method as recited in claim 25, wherein the at least one other 
electronic file is a second electronic document. 

27. The method as recited in claim 26, farther comprising the step of 
generating the second electronic document from an original paper document. 

28. The method as recited in claim 25, wherein the at least one other 
electronic file is an image file. 

29. The method as recited in claim 25, wherein the at least one other 
electronic file is a spreadsheet file. 

30. The method as recited in claim 1, wherein there are a plurality of 
electronic documents associated with the project , and wherein at least a 
subset of the plurality of electronic documents are related to financial 
transactions, the method farther comprising: 

performing a closeout operation with respect to the electronic 
documents, wherein the closeout determines which, if any, of the electronic 
documents are related to incomplete financial transaction. 

3 1 . The method as recited in claim 30, wherein the project has not 
been completed, the step of performing the closeout farther comprises 
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performing a partial closeout, wherein the partial closeout closes out 
electronic documents related to completed financial transactions. 

32. The method as recited in claim 30, wherein the project has been 
completed, the step of performing the closeout further comprises performing 
a full closeout, wherein the full closeout closes out all electronic documents 
related to financial transactions. 



33. The method as recited in claim 30, wherein the step of 
performing the closeout further comprises transferring a balance of a 
completed financial transaction to a General Ledger account. 

34. The method as recited in claim 30, wherein the step of 
performing the closeout is not performed until the project has been 80% 
completed. 

35. A method for automating the management of a project, the 
method comprising the steps of: 

generating at least one electronic document associated with the 
project; . 

identifying entities that comprise an approval hierarchy; 

automatically forwarding a notice requesting approval of the at least 
one electronic document to a successive one of the entities in the approval 
hierarchy upon approval of the at least one electronic document by a 
previous entity in the approval hierarchy; 

a first one of the entities in the approval process requesting 
clarification with respect to the at least one electronic document; 

automatically forwarding the at least one electronic document to one 
of a previous entity in the approval hierarchy and the document originator 
for the requested clarification; 
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second one of the entities in the approval process disapproving the at 
least one electronic document; and 

automatically forwarding the at least one electronic document to one 
of the previous entity in the approval hierarchy and the document originator. 

36. A system for automating the management of a project, the system 
comprising: 

a network; 

a project manager workstation coupled to the network; 

at least one client workstation coupled to the network, wherein the at 
least one client workstation is used to identify entities that comprise an 
approval hierarchy; 

a database server coupled to the network, the database server 
containing at least one electronic document associated with the project; 

a workflow server coupled to the network wherein the workflow 
server automatically forwards a notice requesting approval of the at least one 
electronic document to a successive one of the entities in the approval 
hierarchy upon approval of the at least one electronic document by a 
previous entity in the approval hierarchy. 

37. The system as recited in claim 36, 

wherein one of the entities in the approval process requesting 
clarification with respect to the at least one electronic document; and 

wherein the workflow server automatically forwards the at least one 
5 electronic document to one of a previous entity in the approval hierarchy 
and the document originator for the requested clarification. 

38. The system as recited in claim 37, the system further comprising: 
an electronic notebook associated with the at least one electronic 

document, wherein the requested clarification is generating in the electronic 
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notebook, and wherein the at least one electronic document is forwarded 
back to the entity that requested the clarification. 

39. The system as recited in claim 36, 

wherein one of the entities in the approval process disapproves the at 
least one electronic document, and 

wherein the workflow server automatically forwards the at least one 
5 electronic document to one of a previous entity in the approval hierarchy 
and the document originator. 

40. The system as recited in claim 36, wherein the workflow server 
determines if a monetary value associated with the at least one electronic 
document stored in the database server requires that at least one electronic 
document obtain the approval of a higher level entity in the approval 

5 hierarchy. 

41. The system as recited in claim 36, wherein a substitute entity is 
temporarily substituted for one of the entities in the approval hierarchy. 

42. The system as recited in claim 36, the system further comprising: 
a central storage location coupled to the database server, wherein the 

at least one electronic document is stored in the central storage location and 
wherein the entities in the approval hierarchy can access, review and 
approve the at least one electronic document through the database server. 

43. The system as recited in claim 36, wherein the at least one 
electronic document is a request for assistance that initiates the project. 

44. The system as recited in claim 36, wherein the at least one 
electronic document is a contract. 
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45. The system as recited in claim 36, wherein the at least one 
electronic document is a commitment with respect to a vendor on the 
project. 

46. The system as recited in claim 36, wherein the at least one 
electronic document is a bid. 

47. The system as recited in claim 36, wherein the at least one 
electronic document is a funding document that contains the funding for the 
project. 

48. The system as recited in claim 36, wherein the at least one 
electronic document is a purchase order. 

49. The system as recited in claim 36, wherein the at least one 
electronic document is a change order. 

50. The system as recited in claim 36, wherein the at least one 
electronic document is an invoice approval document. 

51. The system as recited in claim 36, the system further comprising: 
a digital signature attached to the at least one electronic document in 

order to indicate the approval of an entity in the approval hierarchy. 

52. The system as recited in claim 36, wherein there are a plurality of 
electronic documents, the system further comprising: 

a plurality of folders in which the plurality of electronic documents 
are organized. 

53. The system as recited in claim 36, the system further comprising: 



11/8/2006, EAST Version: 2.1.0.14 



WO 01/33477 PCT/US00/41898 

-40- 

a user profile for each user participating in the system, wherein a 
user's access to the at least one electronic document is limited based on a 
parameter in the user profile. 

54. The system as recited in claim 36, the system further comprising: 
an electronic workflow list maintained in the workflow server for a 

user, the workflow list containing a list of electronic documents that require 
an action by the user. 

55. The system as recited in claim 36, wherein the notice forwarded 
on the network. 

56. The system as recited in claim 55, wherein the network is an 
intranet. 

57. The system as recited in claim 55, wherein the network is the 
Internet. 

57. The system as recited in claim 56, the system further comprising: 
a budget for the project stored on the database server; and 

a funding document stored on the database server, wherein the 
funding document is generated using the budget, and wherein the at least one 
electronic document is the funding document. 

58. The system as recited in claim 57, the system further comprising: 
a plurality of pre-existing templates stored on the database server, the 

plurality of pre-existing templates being used for the generation of the 
budget, each of the plurality of pre-existing templates containing a plurality 
of selectable budget items. 
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59. The system as recited in claim 36, the system further comprising 
at least one other electronic file attached to the at least one electronic 
document. 

60. The system as recited in claim 59, wherein the at least one other 
electronic file is a second electronic document. 



61 . The system as recited in claim 60, wherein the second electronic 
document is generated from an original paper document. 

62. The system as recited in claim 60, wherein the at least one other 
electronic file is an image file. 

63. The system as recited in claim 60, wherein the at least one other 
electronic file is a spreadsheet file. 

64. The system as recited in claim 1, wherein there are a plurality of 
electronic documents associated with the project , and wherein at least a 
subset of the plurality of electronic documents are related to financial 
transactions, the system further comprising: 

a general ledger account stored on the database server, the workflow 
server performing a closeout operation with respect to the electronic 
documents, wherein the closeout operation transfers completed financial 
transactions to the general ledger. 

65. The system as recited in claim 36, wherein the network is a 
corporate intranet, the system further comprising: 

a firewall coupled to the corporate intranet and coupled to an external 
network; and 
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a vendor workstation coupled to the corporate intranet through the 
external network and the firewall. 



66. The system as recited in claim 65 wherein the external network is 
the Internet. 
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